Walkie-talkie type services are popular amongst users who wish to communicate brief messages quickly between one another. Walkie-talkie type services are sometimes known as Push-to-talk (PTT) services. Conventionally, such PTT services have been provided by two-way portable radios which utilise a dedicated part of the radio spectrum, but which only allow users to communicate with a small group of pre-selected users who utilise similar terminals and who are within range of the relatively short operating range of the radios. More recently, services have been introduced into the United States which piggy-back on the existing cellular telephone infrastructure. However, these services have been proprietary in nature and have not allowed users to communicate between different operator networks.
In an attempt to broaden the use of PTT services, an industry grouping known as the Open Mobile Alliance (www.openmobilealliance.org) has been established with the aim of standardising suitable protocols which will allow inter-network operability for walkie-talkie services offered over cellular networks. The service established by the various standards is known as Push-to-talk Over cellular (PoC). PoC makes use of the IP Multimedia Subsystem (IMS) to handle the setting up and control of PoC sessions via PoC application servers (acting as SIP ASs). PoC proposes that associated speech data will be transported over a packet switched access technology. In the case of GSM and UMTS, this will be the General Packet Radio Service (GPRS) access technology. In other network architectures, analogous packet switched access technologies will be utilised for transporting talk data. Push to Talk services may also be offered over circuit switched access networks, although this is not the preferred option. The current state of PoC is set out in Release 1.0. The requirements for PoC Release 2 are under discussion. PoC Release 2 will extend PoC to include multimedia and not just speech, and also include a feature that makes it possible to dynamically establish PoC Sessions based on location, presence state and interest.
A Dynamic PoC Group Session can be populated with pre-defined Members, or populated by any user, equipped with a PoC capable device (referred to as a PoC Client) fulfilling the location, presence state and interest criteria. In some cases, a search operation is required in order to populate the PoC Group Session with members.
The Open Mobile Alliance has defined a Search Proxy to coordinate search operations (see OMA-AD-XDM-V2—0-20070724-C), since the search operation may require searches in several databases and in different domains.
In the event that a search operation is required, the PoC Server sends a search request to the Search Proxy. The search request includes required search criteria, and on receipt of the request, the Search Proxy coordinates searches in one or more databases (e.g. there may be more than one domain to search before a complete result can be returned). Once the search is complete, the Search Proxy sends the results of the search to the PoC Server. The results include URIs of PoC Users that meet the search criteria. The search results are then used by a function to evaluate and select PoC User(s) to invite to the Group Session.
If the search criteria are very broad, for example “look for everybody interested in football”, the search may take very long time and/or return a lot of users fulfilling the search criteria, especially if the search is performed over several domains. This may create conflicts between limitations in the SIP protocol (e.g. running timers, etc) and the time it will take to perform the search.
The Search Proxy returns the search result in a single block once the search has been completed. The size of the block can be limited by specifying an optional “max-result” parameter. In this case, the Search Proxy searches until that amount is found or all databases have been searched without finding any users.
The existing technique for searching for members to invite to a Group Session is time-consuming, leading to conflicts with SIP requirements.